# Code review
## Описание
Code review – это проверка исходного кода на ошибки, проблемы архитектуры.

## Почему code review важен?
Помогает:
- Найти баги
- Выявить проблемы в архитектуре
- Сделать код единообразным

А также, что **более важно** в долгосрочной перспективе:
- Это работающий инструмент для обратной связи
- Участники code review будут учиться на своих и чужих ошибках
- Для оценки hard skills разработчика
- Code review поможет делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
- Даёт приток новых идей для улучшений в процессах, подходах и автоматизации
- Децентрализация знаний

## Что будет, если не делать code review?
Будет плохо продукту:
- Баги на production. Тестирование не найдёт все баги
- Технический долг снежным ~~комом~~лавиной накрывает проект. Время разработки новых фич увеличивается экспоненциально
- Подходы и архитектура будут несогласованны. Получится Франкенштейн.

Будет плохо lead-у:
- Плохо знает hard skills разработчиков по отдельности
- Не может оценить производительность

Будет плохо разработчикам:
- Без адекватной обратной связи будет ощущение работы "в стол". Демотивация, депрессия, поиск новой работы
- Не будет притока новых знаний о:
  - Проблемах, с которыми уже столкнулись другие. Учиться на чужих ошибках – это быстро и дёшево
  - Технологиях
  - Вариантах решения проблем
  - Самом проекте

## На кого можно делегировать code review?
В code review желательно участвовать всем разработчикам проекта.

## Примеры поведения
### Примеры плохого поведения
- Токсичное поведение
  - Переход на личности
  - Сарказм
  - Раздражение
- Плохо настроенные процессы
  - Неизвестно, кто должен делать code review
  - Неизвестны критерии прохождения. Процесс может продолжаться бесконечно
  - Список правок не разбит на группы по приоритетам
  - Разработчик долго ожидает code review
  - В merge request приходят огромные фичи
- Software используется недостаточно эффективно
  - Не настроены linter-ы и/или автоматические тесты
  - Разработчики пытаются запомнить список правок
- Разработчику непонятно, зачем нужно вносить правки
- Ревьювер не читал задачу в Jira
### Примеры хорошего поведения
- Адекватная обратная связь
  - Уточняющие вопросы вместо прямого указания на ошибки
  - Нейтральность или доброжелательность
- Процессы помогают ускорить и упростить code review
  - Разработчики понимают, что в их интересах делать code review
  - Все знают список требований для прохождения code review
  - Список правок удобным образом приоритизирован. Например, с помощью emoji 🔥, 💬
  - Обратная связь – быстрая, в идеале – в течение дня
  - Merge requests атомарные
- Для ускорения используются библиотеки и программы
  - Используются linter-ы и автоматические тесты
  - Разработчики не пытаются запоминать список правок в уме
- Участники code review согласны и понимают причины почему нужно внести правки
- Ревьювер знает бизнес-логику решаемой задачи

## Способы прокачки

### Практика и способы прокачки
Code review выглядит просто. Проверяете merge request на ошибки и пишете о них, но есть нюанс. Важно понять и принять, что это долгосрочный процесс. Настоящие причины ошибок – пробелы в знаниях, сниженная мотивация. Lead должен включать soft skills, чтобы не стрелять в ногу себе и команде.

Полезно проводить "review" до написания кода, особенно для junior devs. Lead должен убедиться, что разработчик напишет задачу верным способом. Выяснять нужно с помощью уточняющих вопросов.

#### Умение критиковать

Умение критиковать – это ключевой навык.

##### Как смягчить критику вербально:

- Задавать уточняющие вопросы вместо прямого указания на ошибки
- Сперва похвалить, затем – критиковать
- Хвалите, если всё хорошо
- Feedback от разработчика о том как прошло review. Да, взять и спросить
- Не говорите "ТЫ сделал плохо"

Практиковаться можно "в уме" на merge request. Когда поняли что научились – давать настоящий feedback.

##### Как смягчить критику невербально:
- Следите за эмоциональными состояниями: своим и разработчика

Практикуйтесь "в уме" на косячных merge request. Вы не должны злиться и раздражаться на "эти тупые ошибки 😡". Для настоящих review начинайте с хороших merge requests и постепенно переходите к косячным.

Чтобы не злиться самому помогут:
- Понимание себя и истинных причин раздражения
- Понимание что цель не найти баги, а обучить разработчика не делать их снова; или помочь разработчику сменить позицию или компанию на более подходящую
- Психолог
- ~~Успокоительное~~
- Просто будьте проще, от ваших багов навряд ли кто-то пострадает (с) Капитан Очевидность

Понять что разработчик устал, ненавидит вас, **могут** помочь:
- Практические книги по психологии
- Психологические тренинги

##### Дополнительно

Без невербального общения (переписка в комментариях github) разработчик может додумать ваши эмоции. Старайтесь быть ближе, как минимум – созвонитесь.

#### Процесс review фичи
1. Выяснить, какую бизнес-логику писал разработчик
2. Рассмотреть ключевые элементы бизнес логики, архитектуру решения
3. Углубиться в детали

##### Нужно выяснить какую бизнес-логику писал разработчик
Об этом могут рассказать разработчик, менеджер или таска в jira. Feedback выдаётся разработчику и/или менеджеру при проблемах с бизнес-логикой.

Чтобы прокачать этот скилл можно пройтись по задачам с описанием.

Чтобы получить косячные задачи, можно:
- Зайти в "achieved"
- Попросить придумать косячные задачи
- Или попросить придумать задачи косячного менеджера

Результат – понимание задачи или аргументы что не так с задачей. Возможно – список на исправление.

##### Рассмотреть ключевые элементы бизнес логики, архитектуру решения
Об архитектуре решения и ключевых моментах расскажет разработчик. Feedback нужно выдать ему же.

Практиковаться можно на merge request вместе с разработчиком.

Разработчик самостоятельно расскажет о проблемах, если его спросить. Также он сможет аргументировать, почему он выбрал определённое решение.

Результат – понимание и принятие или аргументы:
- Почему это нужно исправить
- Что будет, если не исправить
- Соглашение с разработчиком как исправить

##### Углубиться в детали
На проекте должен быть linter. Он проверяет отступы, использование необъявленных переменных и другую головную боль.

Если это необходимо – пройдитесь по деталям реализации.

Результат – статус задачи "review закончено" или аргументированный список правок.

#### Что ревьюить
В зависимости от целей ревью и времени на него:
- Наиболее критичные задачи
- Практики безопасности
- Архитектуру
- Задачи junior devs
- Все задачи
- Выбранное вами

Вы должны чётко осознавать, что именно и зачем вы ревьюите.

#### Настройка и использование software
##### Автоматическая проверка кода
Для ускорения процесса нужно настроить проверку кода на:
- Синтаксические ошибки
- Стилистические неточности
- Предполагаемые ошибки во время исполнения (использование необъявленной переменной и тд)
- Возможные уязвимости в коде и используемых библиотеках

Это поможет сократить время на поиск проблем вручную.

##### Комментарии
Не полагайтесь на память. Git хостинги дают комментировать участки кода, вести дискуссии. Критичные правки можно записывать например в комментарии к merge request.

Можно настроить автоматическую синхронизацию комментариев с мессенджером.

##### Интеграции

- Git хостинги умеют слать на почту сообщения, связанные с code review
- Можно добавить интеграцию через API, чтобы слать сообщения в мессенджер
  - О новых merge requests
  - Об утверждённых merge requests
  - О merge requests которые долго никто не проверял
  - Комментариях к коду

#### Работа с другими процессами

- **CI/CD**. Если встроить code review в процесс CI/CD, то на выходе можно будет получать более надёжный продукт

## Вопросы для собеседования
- Blitz
  - Что такое code review?
  - Организован ли у вас в команде code review?
  - Может ли code review помочь найти баги, которые не может найти тестировщик?
- Вопросы "на подумать"
  - Какие плюсы даёт code review в общем и вашей команде?
  - Можно ли не делать code review? В каких случаях?
  - Сколько времени можно тратить на code review?
  - С какими процессами в команде можно интегрировать code review?
  - Во время code review вы увидели токсичное поведение одного из ревьюеров; например, сарказм, грубость. Нужно ли с этим что-то делать? Если да, то что?

## Консультации
- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp)
- [Психологи на b17.ru](https://www.b17.ru)

## Теория
### Статьи
**Раскрывают тему:**
- [Code review по-человечески (часть 1)](https://habr.com/ru/post/340550/)
- [Code review по-человечески (часть 2)](https://habr.com/ru/post/342244/)
- [Pull Requests and Code Review](https://medium.com/@pstepchenko/pull-requests-and-code-review-30abde0c98d3)
- [Unlearning toxic behaviors in a code review culture](https://medium.com/@sandya.sankarram/unlearning-toxic-behaviors-in-a-code-review-culture-b7c295452a3c)

### Видео

- [Automating code reviews](https://sobolevn.me/talks/dumpconf-2019)
